Learning objectives
What you will be able to do
By the end of this module, you will have the conceptual foundation for every decision you make as a Domain Owner.
🎯
Describe the business layer in your own words
Explain what "owns the business layer" means day-to-day, without jargon.
🔄
Articulate the mindset shift
Contrast your previous role's focus with what the Domain Owner role demands.
📂
Explain why documentation beats memory
Give at least two reasons why domain knowledge must live in files, not heads.
⚖️
Identify your decision authority
Name the three categories of decisions that belong exclusively to you.
🤝
Know where Domain Owner ends and AI Engineer begins
Correctly route at least 5 decision scenarios to the right role.
Lesson 1 · Core concept
What "owns the business layer" means in daily practice
The Agentic FX Dev Squad has two humans and many AI agents. Of those two humans, one — the AI Engineer — owns the technical infrastructure. The other — you, the Domain Owner — owns everything that is about the business: what should be built, why it matters, and whether it was built correctly.
The phrase "business layer" refers to all the knowledge, rules, and intent that exist outside of code. It is the reason the feature exists at all. It answers: Who asked for this? What problem does it solve? What does "correct" look like from a user or stakeholder perspective?
💡
Simple definition
The business layer is the set of facts, rules, and priorities that only humans with domain knowledge can supply. AI agents can generate code, draft specs, and write tests — but they cannot know what the business actually needs. That is your job.
Business rules
The logic the system must enforce because the business requires it — independent of how it is implemented. Example: "A FX trade confirmation must be sent within 2 minutes of execution."
Domain knowledge
The accumulated understanding of how your industry, users, and internal processes work. It is what lets you say "that's not how our traders actually behave" when reviewing a spec.
Acceptance criteria (AC)
The written, agreed conditions under which a feature is considered done from the business perspective. The Domain Owner defines these and is the final arbiter of whether they were met.
Personas
Descriptions of the real people who will use the system — their goals, mental models, and pain points. You maintain these so agents generate specifications grounded in actual user reality.
In practice, "owning the business layer" looks like this across a typical week: you review a problem statement and clarify the stakeholder intent; you read an AI-generated spec and correct two AC conditions that misrepresent how the product actually works; you manually walk the P0 acceptance criteria before sign-off. You are the human who keeps the AI honest about what the business needs.
Lesson 2 · The transition
Shift: from verifying output → defining expected outcomes
This is the hardest part of becoming a Domain Owner, especially if you come from a QC background. In QC, you respond to what has been built. In the Domain Owner role, you shape what gets built — before a single line of code is written.
← Previous role thinking
- "Does this button work correctly?"
- "Does the output match the requirement?"
- "I found a bug — I will log it."
- React to what was built
- Validate after the fact
- Focus on defect detection
→ Domain Owner thinking
- "Was the right thing specified to begin with?"
- "Does this AC reflect actual user intent?"
- "This spec is missing an edge case — I will fix it now."
- Define what should be built
- Validate before build starts
- Focus on outcome definition
⚠️
The most common early mistake
New Domain Owners continue thinking in test-execution mode. They wait for the build to finish, then review it. By then, a flawed spec has already been implemented. The Domain Owner's greatest leverage is upstream — at the spec and AC definition stage, not at the test stage.
This shift is also about temporal position. QC work happens after Phase 3 (Build). Domain Owner work is highest-value in Phase 1 (Capture) and Phase 2 (Spec). You still have a role in Phase 5 (Test) — manually validating P0 ACs — but if you only show up at Phase 5, you have already missed your biggest opportunity to improve quality.
Capture — highest DO leverage
You review the problem statement and collect missing business context before the spec is drafted. A clear problem statement means the AI generates a better spec. A vague one compounds into every downstream phase.
DO: clarify intent, fill information gaps
Spec — high DO leverage
You review the AI-generated spec.md, correct business logic errors, and formally approve. This is the last checkpoint before code is written. Every error you catch here is free; every error you miss here is expensive to fix later.
DO: review spec, correct AC, approve or return
Build — shared monitoring
Both roles monitor and unblock agents. You may be called to resolve ambiguities about business logic that surface during implementation.
DO: unblock on business logic questions
Review — business findings
The AI code-reviewer flags findings. You resolve any finding labelled "business logic / AC misread" — these belong to you, not the AI Engineer.
DO: resolve business logic / AC misread findings
Test — manual P0 walk
You manually walk each P0 acceptance criterion and check it off in acceptance-criteria.md. This is confirmatory, not exploratory — the hard thinking was done in P2.
DO: walk P0 ACs, check off acceptance-criteria.md
Ship — release review
You review the 3-bullet release summary for accuracy before archiving. Your confirmation that P0 ACs are satisfied is one of two required ship gates.
DO: review release summary, confirm P0 ACs ✓
Lesson 3 · Documentation discipline
Why domain knowledge must be documented, not just known
You may be the most experienced person on the team when it comes to FX domain knowledge. That expertise is valuable — but only if it is accessible. In the Agentic Dev model, your knowledge is consumed primarily by AI agents who read your docs/domain/ files before generating specs. If your knowledge is in your head and not in those files, it does not exist for the agents.
🔶
Why "I'll remember" is a liability
The product-domain-expert agent writes spec drafts based on what it can read. It cannot interview you. It cannot ask what you know. If the business rule "FX confirmations for trades above $10M require dual authorisation" is not in docs/domain/business-rules.md, the agent will draft a spec that silently omits it — and that error will propagate to code, tests, and the release.
There is a second reason: consistency under rotation. If you are unavailable, someone else becomes the Domain Owner for a sprint. If all knowledge lives in structured domain files, that person can onboard in minutes. If it lives in your head, the squad stalls.
The rule is simple and non-negotiable: update docs/domain/ before you edit any spec. This creates a forcing function. Every time something new becomes clear about the domain — a new business rule, a clarified persona, a corrected glossary term — it gets written down before it shapes any spec.
✅
The three files you own in docs/domain/
business-rules.md — Constraints and logic the system must enforce (covered in Module 02)
glossary.md — Agreed definitions of domain terms so spec language is unambiguous
personas.md — Descriptions of real user types, their goals, and their context
Lesson 4 · Your authority
Your authority: scope, AC correctness, and business logic disputes
Authority in the squad is not about seniority or title. It is about domain of accountability. As Domain Owner, three categories of decisions are yours alone — not shared, not deferred, not overridden by the AI Engineer or by agents.
Scope authority
What is in scope vs. out of scope is your call. The AI Engineer may flag technical implications of scope choices (e.g., "adding X doubles the build time"), and you should factor that in — but the final decision is yours. No agent or engineer can expand or shrink scope without your agreement.
AC correctness authority
You are the final arbiter of whether acceptance criteria correctly represent business intent. The AI can draft AC. You decide if the draft is right. If an AC condition misrepresents how the business works, you correct it — and your correction is final.
Business logic dispute authority
When a code review finding is labelled "business logic / AC misread", that finding belongs to you to resolve. Was the AC ambiguous? Was it misread? Was it correctly implemented but wrong to begin with? You answer these questions. The AI Engineer resolves technical findings; you resolve business ones.
🔑
Authority comes with accountability
Owning these decisions also means owning the consequences. When you approve a spec, you are committing that the business requirements it contains are correct. When you sign off on P0 ACs, you are committing that the feature is ready to ship from a business perspective. These are not administrative checkboxes — they are professional accountabilities.
Lesson 5 · Decision boundaries
Where Domain Owner ends and AI Engineer begins
One of the most important skills in a two-human squad is knowing when to step forward and when to step back. Overstepping into the AI Engineer's domain creates friction and confusion. Under-stepping leaves business decisions unmade or made by the wrong person.
| Decision |
Domain Owner |
AI Engineer |
| Is this idea worth speccing? |
● Both — DO on business value |
● Both — AIE on feasibility |
| What's in scope vs. out of scope? |
● Domain Owner decides |
Flags technical implications only |
| Are the acceptance criteria correct? |
● Domain Owner approves |
Reviews for technical clarity |
| Is the code architecturally sound? |
Not your call — trust AIE |
● AI Engineer decides |
| Which AC was misunderstood in review? |
● Domain Owner resolves |
Resolves technical review findings |
| Do tests cover enough business scenarios? |
● Both — DO on scenario completeness |
● Both — AIE on coverage % |
| Is the feature ready to ship? |
● DO: all P0 ACs ✓ |
● AIE: all tests green |
The key principle: if the question is about what the system should do, it is yours. If the question is about how the system does it, it belongs to the AI Engineer. When in doubt, ask yourself: could a business stakeholder with no technical knowledge answer this question? If yes — it is a Domain Owner question.
Scenario A
"The code-reviewer agent flagged that our FX rate rounding logic rounds to 4 decimal places, but the AC says 5. Who resolves this?"
Domain Owner. This is a business logic / AC misread finding. You determine whether the business intent was 4 or 5 decimal places and whether the AC needs to be corrected or the code does.
Scenario B
"The AI Engineer says the implementation will be 40% slower if we include real-time rate streaming in scope. What do you do?"
Domain Owner decides scope. You listen to the technical implication, weigh it against business priority, and make the call. You may choose to include it, remove it, or defer it — but the decision is yours to make.
Scenario C
"A test suite is showing 87% branch coverage. Is that enough?"
Split. The coverage percentage question belongs to the AI Engineer. Whether the scenarios covered represent the real business cases is your question. You need to check: are the critical P0 business paths in that 87%?
Scenario D
"The AI Engineer wants to refactor the database schema to improve query performance. Should they proceed?"
AI Engineer's call. This is an architectural decision that does not change what the system does — only how it does it. You do not need to approve this. Trust the AI Engineer's judgment here.
Knowledge check
Test your understanding
1. A new backlog item has been added with a vague problem statement. In which phase is your intervention most valuable?
APhase 5 (Test) — walk the ACs after the feature is built to catch any misalignment
BPhase 1 (Capture) — clarify intent and fill information gaps before the spec is drafted
CPhase 3 (Build) — monitor the agents and correct them if they build the wrong thing
DPhase 6 (Ship) — review the release summary to confirm what was delivered
2. A code reviewer agent flags: "The confirmation timeout is set to 90 seconds in code, but the AC states 120 seconds — business logic / AC misread." Who resolves this?
AThe AI Engineer, because it involves a code value
BThe code-reviewer agent, because it flagged the issue
CThe Domain Owner, because it is a business logic / AC misread finding
DBoth roles jointly, through a formal escalation meeting
3. A business rule about FX trade authorisation thresholds is well-known by the team but not written in docs/domain/business-rules.md. What is the risk?
ANo real risk — the AI Engineer can ask the Domain Owner directly during the build
BMinor risk — the agent will probably infer the rule from similar features
CHigh risk — the product-domain-expert agent drafts specs from files it can read; undocumented rules are silently omitted
DNo risk — the Domain Owner will catch it during the Phase 5 AC walk
4. The AI Engineer proposes refactoring the matching engine to use an event-driven architecture for better scalability. Do you need to approve this?
ANo — architectural decisions about how the system works belong to the AI Engineer
BYes — all changes to the system require Domain Owner sign-off
CYes — the Domain Owner must assess whether the refactor changes business behaviour
DOnly if it affects the project timeline
5. Which statement best describes the Domain Owner's relationship with the ship gate?
AThe Domain Owner reviews the AI Engineer's test results and approves them
BThe Domain Owner's approval is optional if all automated tests pass
CThe Domain Owner must independently confirm all P0 ACs are satisfied — this is a required gate alongside the AI Engineer's test green gate
DThe ship decision belongs to the AI Engineer; the Domain Owner only reviews the release summary
Module 01 — Key takeaways
- The business layer is everything the system must do and why — and you are its owner and guardian.
- Your highest-leverage intervention is upstream: Phase 1 and Phase 2, before anything is built.
- AI agents generate from what they can read. If it is not in
docs/domain/, it does not exist for the squad.
- Scope, AC correctness, and business logic dispute resolution are yours alone — not shared with agents, not deferred to the AI Engineer.
- If a question can be answered by a business stakeholder with no technical knowledge, it belongs to you. If it requires technical knowledge, it belongs to the AI Engineer.
Up next
Module 02 — Owning docs/domain/
Learn what goes in each domain file, when to update them, and how agents consume them.
Module 02 →